>From the keyboard of rwu@ibism.UUCP (Raymond Wu):
:Hello netters...
:
:We're contemplating writing our version of passwd which will enforce
:the compliance of passwords to our corporate security standards - such as not being in a dictionary, min/max legnths, patterns, etc.
:
:Being new to the Un*x world, I see several ways of implementing this - writing setuid scripts incorporating calls to crypt and awk to effect new passwords or
:writing setuid code to effect the change of the passwd / passwd.adjunct files - replacing the passwd utility.
:
:What are the (dis)advantages/hazards/risks of doing it either way?
:
:I heard somewhere that setuid scripts represents a major security hole in that a setuid script can be interrupted in such a manner that another non-setuid script can be executed in this place....??
PLEASE PUT THIS ON THE FAQ AND PUT IT TO REST.
You can't make suid shell script secure. Only a fix to the kernel will do this.
Awk and crypt? You've got to be kidding.
You should look at Larry Wall's passwd program. It probably does all you want.
And please use carriage returns.
Here's an old posting of mine (plus someone else's) about this.
--tom
When you execute a shell script, what really happens is that the kernel
opens the file you asked it to run, sees the magic number of "#!", and
then calls the interpreter following that to run the script for you.
The problem is that it passes the name of the script to the shell, and
the shell must then reopen the script. That means we opened the script
twice.
Consider the following scenario: /usr/local/bin/zot is a suid shell
script. ~/snark is a symlink pointing to zot. ~/gotcha is some
program that if run as root would compromise security, such as by
giving me a root shell.
I type something like "nice +64 snark &" and let the kernel ever so
slowly decide to call the shell with an argument of snark. It's
already set the euid to root because it's pointing to zot, which is
suid root. Now the shell ever so slowly starts up. In the meantime, I
make snark point not to zot but to gotcha. Bingo! By the time the
suid shell opens snark, it gets gotcha instead of zot, and the whole
system is down the tubes.
As you see, the presence of ANY suid script on a system allows anyone
to run anything as root. This is obviously a very bad thing.
Now, if the suid script is in perl or ksh, they should keep working
because these programs have alternate versions of themselves (suidperl
and suid_exec) installed suid for just this reason. (Theoretically --
last I checked suid_exec wasn't installed right.) Csh and sh scripts,
however, will not work.
Several work-arounds exist. It's bad to have a suid script anyway, but
if you really must, then you're going to have to make a C wrapper
around it that sets the uids the way you want them and then invokes the
shell. The easiest way to do this is using the op utility, which was
designed for this very thing. See the alt.sources posting, or mail me.
Here is an additional posting on the subject. Even wrappers don't get
around these problems. I'd never trust a shell to run anything with
euid != uid. Maybe perl; taintperl is pretty clever.
--tom
------- Forwarded Message
Date: 10 Aug 90 19:41:32 GMT
From: vlb@magic.apple.com (Vicki Brown)
Subject: Re: Suid script security
Organization: Apple Computer
Newsgroups: comp.unix.questions
In article <14920003@hpdmd48.boi.hp.com> markw@hpdmd48.boi.hp.com (Mark Wolfe) writes:
>
> I know that suid scripts are a bad idea from reading comp.questions and
>comp.wizards over the last year or so. It seems that just about every guru
>in the world has posted a warning NOT to do it, so I decided I would follow
>the advice (it's a rare subject that all guru's agree on). However, it appears
>that I'm now about to have one of these ugly animals forced on me from above,
>so I'd like some advice:
>
> 1) Just what are the security risks involved? (i.e. how would someone attack
> a system via one of these).
>
> 2) What can I do to make this as secure as possible?
Warning - very long response ahead. Proceed at your own risk.
There was a very interesting paper in the USENIX Association's publication,
;login: ( "How To Write a Setuid Program", Matt Bishop, ;login:
Vol 12, Number 1, January/February 1987). An excerpt:
Some versions of UNIX allow command scripts, such as shell scripts,
to be made setuid ... Unfortunately, given the power and complexity
of many command interpreters, it is often possible to force them to
perform actions which were not intended, and which allow the user to
violate system security. This leaves the owner of the setuid script
open to a devastating attack. In general, such scripts should be avoided.
... suppose a site has a setuid script of sh commands. An attacker
simply executes the script in such a way that the shell ... appears
to have been invoked by a person logging in. UNIX applies the setuid
bit on the script to the shell, and ... it becomes interactive...
One way to avoid having a setuid script is to turn off the setuid
bit on the script, and ... use a setuid [binary] program to invoke it.
This program should take care to call the command interpreter by its full
path name, and reset environment information such as file descriptors
and environment variables to a known state. However, this method
should be used only as a last resort and as a temporary measure,
since with many command interpreters it is possible even under these
conditions to force them to take undesirable action.
The biggest problem with shell scripts is that you (the programmer /
administrator) have very little control over the programs which run within
the script. As a very real example, I ran across a script which allowed
users to enter bug reports, using the "vi" editor. The script was
setuid root, because it wanted to save files in funny places. The programmer
had guarded against shell escapes (a known feature of vi), by making this
script the login shell. However, he couldn't guard against another feature
:e /etc/passwd
You can attempt to make your script as safe as possible by
1) being very restrictive in your choice of UID. That is,
make the script setuid for a non-privileged user, rather than root
(for example, if it must write a log file, could the log file
live in some locked area, accessed only by a new and otherwise
non-privileged account?)
2) making the script setgid rather than setuid, with a very
restricted GID (see #1)
3) ensuring that the script is short, very simple, and does not
make use of commands such as `vi', `mail' or anything interactive.
setuid programs should do ONE thing only, and in a non-complex
manner.
4) setting the PATH, IFS, and other environment variables explicitly
within the script
5) locking down the permissions on the script. If possible allow it
to be run only by group members. Never allow write permission.
6) If your version of UNIX permits, take away read permission for
anyone other than the owner. It's a bit harder to break
something if you can't see how it works.
7) Rewrite it in C (carefully)
8) Convince your management that they don't really need this.
If you plan to keep the script, or re-write it, try and get a copy of the
paper. If you can't find it, send me mail.
Vicki Brown A/UX Development Group Apple Computer, Inc.
Internet: vlb@apple.com MS 58A, 10440 Bubb Rd.
UUCP: {sun,amdahl,decwrl}!apple!vlb Cupertino, CA 95014 USA
Ooit'n Normaal Mens Ontmoet? En..., Beviel't?
(Did you ever meet a normal person? Did you enjoy it?)
